The present invention relates to serialization of resources.
In a multitasking, multiprocessing environment, resource serialization is the technique used to coordinate access to resources that are used by more than one application. Programs that change data need exclusive access to the data. Otherwise, if several programs were to attempt to update the same data at the same time, the data could be corrupted.
Serialization of resources typically falls into one of two categories: (1) nearly instantaneous, i.e., for the duration of an instruction or a few instructions, such as when updating a counter; and (2) longer term, usually accomplished through the use of a lock, latch, semaphore, token, or similar construct (referred to herein as a “serialization mechanism” or “SM”), such as when updating several related values or managing a linked list. The first method is commonly referred to as “latchless serialization,” and will be referred to herein as “no-SM serialization.”
The first method generally offers better performance while the second generally offers much greater flexibility. In most cases, the choice to use one method or the other is clear. However, it is possible to have a situation in which one method may be preferred most of the time but the other method is occasionally needed. The serialization mechanism can also be used to halt activity on a particular resource. The no-SM method provides no way to suspend activity, as the only alternative to an eventual successful update is to force a failure that will not be retried. Both methods cannot be used at the same time without imposing a hierarchy that requires both mechanisms to be used in a certain order. A common way of handling this situation is to use a serialization mechanism if there is ever going to be a need to do so. This sacrifices performance but provides the function that is needed.